home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 643 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.8 KB
  1. Path: chronicle.mti.sgi.com!austern
  2. From: rmcinnis@gate.net (Robert B McInnis)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Generic Object Callbacks
  5. Date: 06 Mar 1996 09:40:37 PST
  6. Organization: 9th Bit Software
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <4hk8g7$2bcq@news.gate.net>
  9. References: <4h5j7b$1ur@bcarh8ab.bnr.ca>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: 6 Mar 1996 14:46:31 GMT
  12. X-Newsreader: News Xpress Version 1.0 Beta #4
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBVAwUBMT3OIky4NqrwXLNJAQHW4wH/daq5CUAVKq3fqB3TZ+f8oXjoV1SbTFj+
  15.     t0zIIizjnZhz2Oge4XQ0auUapmvTgIozSVAfwO7ZoXxr4eFeDa9VJw==
  16.     =Znb9
  17. Originator: austern@isolde.mti.sgi.com
  18.  
  19. In article <4h5j7b$1ur@bcarh8ab.bnr.ca>, "ian (i.) willmott" <willmott@bnr.ca> 
  20. wrote:
  21.  
  22. >The point is that the "driver" shouldn't have to know the type of the object 
  23. the
  24. >callback is directed at. This is particularly important when the "driver" 
  25. issuing
  26. >the callback is a library API, such as Motif; you do not want the library to 
  27. have
  28. >to know about application data types and you do not want to constrain the 
  29. application
  30. >to use a single callback object type that is defined by the library. The 
  31. point of the
  32. >proposal is that there is a simple extension to the language which would 
  33. accomplish
  34. >this in a type-safe way.
  35.  
  36. I agree, the orginator of an event should not know about the destination of 
  37. the message.  Also, it should not care how many destinations it has.  In this 
  38. way, you are involving loose couling and the "observer" pattern combined.  
  39. There is a simple way to ensure type safe, loosely coupled callbacks.  
  40.  
  41. Using a stand alone object to represent the event, that contains a polymorphic 
  42. list of callback "nodes", you can acheive the desired result.  Each node of 
  43. the list could be a templated sub-class that only takes qualified types and 
  44. redefines a virtual to make the call to the specified type.  Once the event 
  45. object has been "invoked", it will cycle through the list and call the virtual 
  46. function to invoke each message.  The message could be a pointer to a C 
  47. function, a static member function, or a public member function for a specific 
  48. instance of a class. 
  49.  
  50. Doing it this way will ensure you type safety, and flexibility for attaching 
  51. to objects that are from an otherwise unknown class hierarchy.
  52.  
  53.  
  54. >The real problem is that it's difficult to write an object-oriented API for a
  55. >system like X because C++ as currently defined doesn't provide 
  56. type-independent
  57. >object callbacks. The proposed language extension would greatly facilitate 
  58. the
  59. >creation of object-oriented, event-driven API's.
  60.  
  61. No necessarily the case.  Developing a stand-alone object would allow you to 
  62. "attach" an event to any object.  This would allow for an int to emit a 
  63. value-change event or a system file to emit a file-change event or whatever.
  64.  
  65. If anyone would like further information and/or and example, please eMail me 
  66. and I'd be glad to give you a demonstration.
  67.  
  68. My thought is that the STL should contain such an object so as to allow 
  69. developers a standardized way of approaching system coordination problems.  I 
  70. also beleive that the base types should have this capability, so I can hook 
  71. into an int's value-change callback.  I have redefined a set of classes to do 
  72. this on my own, but it would be nice it the committees put it in the 
  73. standards.
  74.  
  75. Rob
  76.  
  77. -----------------------------------------------------------------------
  78. Robert McInnis
  79. 9th Bit Software
  80. (eMail)  rmcinnis@gate.net
  81. (pager)  813/216-8329
  82.  
  83. - These ramblings have come from a loosely coupled mind
  84. ---
  85. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  86.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  87.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  88.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  89.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  90. ]
  91.